The same change can be effected from within a process using schedctl(), as shown in Example 6-3.
Example 6-3 : Setting a Real-Time Priority
if (-1 == schedctl(NDPRI,0,38))
{
if (EPERM == errno)
fprintf(stderr,"You forget to suid again\n");
else
perror("schedctl");
}
The real-time priorities are those numerically less than or equal to the system tuning parameter ndpri_lolim, which is normally 39. You can view or change ndpri_lolim using systune, as shown in Example 6-2.The kernel guarantees that a runnable process with one of the real-time band of priorities will never sit idle waiting for a process with a lower priority.
The preemptible network daemon, rtnetd, which is used by default on multiprocessor systems, normally runs at a nondegrading priority of 39. If you give a process a superior (numerically smaller) priority value, it cannot be preempted by network I/O. This can affect network operations.
Caution: If a process with a real-time priority goes into a loop, it can monopolize its CPU, excluding all other processes. On a multiprocessor system, a runaway real-time process is not the disaster it would be on a uniprocessor. You can kill the looping process with a command executed on another CPU. However, if you have isolated all but one CPU, for example by running the Frame Scheduler on all other CPUs, a high-priority process on the remaining CPU can lock the entire system. A looping process with priority 30 can lock out all other processes, including network and NFS daemons and the X-server, making the system unusable.